Managing record events

ABSTRACT

Systems, methods, and computer program products for managing and prioritizing record events. A priority manager includes an event list that lists scheduled record events. Each event in the event list has a priority that is different from the other events in the event list. If some of the events conflict, such as when a tuning resource is lost and unavailable, then those events with the highest priority in the event list are recorded. A user can assign priority to events when they are scheduled or at a later time. This enables event conflicts to be resolved by the user when the events are initially scheduled. When an event conflict arises later, the conflict is resolved by the priority manager according to the relative priority of the events in the event list.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. application Ser.No. 10/131,661, filed Apr. 24, 2002 and entitled “Managing RecordEvents”, now issued as U.S. Pat. No. ______, on ______, and which isincorporated herein by this reference, in its entirety.

BACKGROUND OF THE INVENTION

1. The Field of the Invention

The present invention relates to managing and scheduling events. Moreparticularly, the present invention relates to systems, methods, andcomputer program products for managing record events using a prioritymanager to resolve conflicts that occur between some of the recordingevents.

2. Background and Relevant Art

Today, many devices have the ability to digitally record a video streamsuch as a television program. The recorded video streams are oftenstored on a hard drive where they may be viewed at the leisure of auser. In fact, some homes have more than one device that is able torecord video streams. In addition to viewing and recording videostreams, these devices often provide other functionality to users, suchas browsing the Internet.

Even though a network may have more than one device that can view andrecord video streams, the number of video streams that can beconcurrently recorded is often limited by the number of tuners that arepresent in the recording devices. Tuners are effectively a limitedresource and users encounter situations where they want to concurrentlyrecord more video streams than they have tuners. Because of theseconflicts, there is a need to determine which video streams or programsshould be recorded.

There are many situations that can create an event conflict such as arecording conflict. For example, a recording conflict can occur when oneof the programs to be recorded is rescheduled to broadcast at adifferent time that coincides with an already scheduled event. Therescheduled program is often reflected, for instance, in the guide datathat is supplied to the recording device. Recording conflicts can alsooccur when a program runs longer than its scheduled time. In otherwords, a particular program may not end at its scheduled time, it may beinterrupted by a breaking news story, and the like. Sporting events area typical example of a program that may not end at a scheduled time. Theability to record beyond the scheduled ending time may conflict withanother event that is already scheduled. Another situation where arecording conflict occurs is when a user schedules too many programs torecord concurrently.

The complexity of managing these conflicts increases because of theflexibility the user has in scheduling recording events. A user, forexample, can schedule an entire season of a particular program to berecorded. However, future guide data is limited in scope and potentialconflicts cannot be determined when the record event is scheduled. Someof the future programs, for example, may not air on the same day or theweek or they may be special episodes that last longer than normalepisodes.

In another example, the user may schedule record events that aredependent on characteristics of the programs. For example, the user maywant to record all programs that have a particular actor, which isdetermined by searching the guide data. These types of events causeconflicts that become known at a later time after these programs havebeen identified and scheduled. For at least these reasons, recordingconflicts are practically inevitable.

SUMMARY OF THE INVENTION

The present invention recognizes the limitations of the prior art andthe need for systems, methods, and computer program products that areable to manage and schedule events including record events. Inaccordance with the present invention, a priority manager enables a userto resolve conflicts when the event is initially scheduled. The prioritymanager also resolves conflicts in the absence of user input accordingto the priority of the events that are currently scheduled.

When a user schedules an event, the priority manager permits the user toestablish the priority of the event or program. By default, an eventreceives the lowest priority in the priority manager if the priority isnot set or assigned by the user. The priority manager is able toprioritize all types of record events, including but not limited to,single record events, series record events, smart record events, andmanual record events.

Scheduled record events with higher priorities record before events oflower priority. Thus, if too many events or programs are scheduled torecord concurrently, then those events or programs with the highestpriority will be recorded and those with lower priorities will not berecorded. In this manner, the priority manager is able to resolvescheduling or recording conflicts that are not resolved by the user.

The user also has the ability to change the priority of any event. Bychanging the priority of an event, the user can thus resolve some of therecording conflicts before they occur and the priority manager ensuresthat high priority events are performed. In one example, a user mayassign a low priority to an event that conflicts with another event. Thenew event will only record, for example, if higher priority events arecanceled, rescheduled, or the like.

In some instances, there may be insufficient storage space on therecording device to successfully record all of the scheduled events.Another aspect of the present invention relates to deleting events orprograms in order to provide sufficient storage space. This can beaccomplished using the priority manager to pre-age recorded programs orscheduled events and recommend programs and/or events for deletioninstead of simply deleting the oldest recording(s). The necessarystorage space can also be provided by deleting recoverable resourcesthrough reprioritization. For example, the guide data can be searched todetermine if a program currently recorded is broadcast in the future. Ifthe program is broadcast in the future, then that program can be deletedand re-recorded on the future broadcast date.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be obvious from thedescription, or may be learned by the practice of the invention. Thefeatures and advantages of the invention may be realized and obtained bymeans of the instruments and combinations particularly pointed out inthe appended claims. These and other features of the present inventionwill become more fully apparent from the following description andappended claims, or may be learned by the practice of the invention asset forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 illustrates exemplary sources that deliver content to a set topbox and further illustrates an exemplary environment for implementingthe present invention;

FIG. 2 illustrates a set top box including a priority manager formanaging record events that are recorded using tuner resources;

FIG. 3 illustrates exemplary types of record events;

FIG. 4 illustrates a priority manager that has a list of prioritizedrecord events and also illustrates that different applications haveaccess to the priority manager;

FIG. 5 is a flow diagram illustrating an exemplary method for managingrecord events that conflict with other record events; and

FIG. 6 illustrates an exemplary system that provides a suitableoperating environment for the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The number of events that can be concurrently performed by a system suchas a set top box or a network is often limited by the resources of theset top box or the network. With respect to record events, the number ofvideo streams that are scheduled to be concurrently recorded by a settop box or by a network that has access to tuning resources is limitedby the number of tuners that are available in the tuning resources ofthe set top box or network. Because of this limitation, it is possiblethat the tuning resources of the set top box/network will not be able tosuccessfully record all of the video streams that are scheduled forrecording.

The present invention relates to systems, methods, and computer programproducts for record events using a priority manager. The prioritymanager provides flexibility to the user and is not limited to makingrecording decisions based on when the record event is scheduled, whichis often the case with first in first out (FIFO) and last in first out(LIFO) recording mechanisms.

The present invention provides a priority manager that manages all typesof record events by assigning a priority to each record event. None ofthe scheduled record events will have the same priority and the prioritymanager is accessible to the user from various applications. Thepriority manager, for example, is available when the user schedules anevent such that a potential conflict can be resolved when the event isscheduled by allowing the user to assign a preferred priority to some orall of the scheduled events. When the user is unable to resolve theconflict, then the scheduled events are recorded according to theirassigned priority.

FIG. 1 illustrates an exemplary environment for implementing the presentinvention. FIG. 1 illustrates a source 100 that is connected with a settop box 110. Exemplary sources include, but are not limited to, asatellite system 102, a cable system 104 and the Internet 106. Thecontent or data that is available from the source 100 includes, but isnot limited to, audio/video data, video streams, text, guide data,services, software updates, advertisements, image data, other data andthe like or any combination thereof

The set top box 110 is an exemplary computing environment that is ableto receive, send and process content. Exemplary set top boxes include,but are not limited to, digital video recorders (DVRs), satellitereceivers, Internet terminals, cable boxes, digital satellite systems(DSS), and the like or any combination thereof. The set top box 110, forexample, may also function as a server computer for a home network. Inthis situation, the set top box 110 would distribute content from thesource 100 to other set top boxes.

FIG. 2 illustrates an exemplary set top box where the present inventionmay be implemented. The set top box 110 includes a storage 204, such asa hard drive or other storage device. The set top box stores recordedprograms 206, guide data 208, and other applications and data on thestorage 204. The guide data 208 describes some of the content that isavailable from the source 100 illustrated in FIG. 1. The guide data 208includes, but is not limited to, program start times, program end times,program titles, program duration, ratings, actors/actresses, and thelike and any combination thereof.

The set top box 110 also has tuner resources 210. The tuner resources210 include tuners 211, 212, and 213. The tuner resources 210 are usedto retrieve or receive content from the sources 100. When a livetelevision program is being watched by a user, for example, a tuner isrequired to view the program. A tuner is also required to record aprogram. In this specific example, the set top box 110 is able toconcurrently record three programs or video streams because the tunerresources 210 include three tuners. It is understood by one of skill inthe art that the set top box 110 may include any number of tuners andthat the number of concurrent recordings is limited to the number oftuners.

The set top box 110 also includes a priority manager 220 that managesrecord events 222. While the present invention is discussed in terms ofrecord events, it is understood that the principles taught herein can beapplied to other types of events such as delete events or reminderevents. The record events 222 are created by the scheduler 202 and areordered according to their priority. By default, newly scheduled eventshave the lowest priority unless altered by the user or the set top box110.

The ability to change the priority of a particular event can occureither explicitly or implicitly. For example, the record events 222 canbe displayed to a user and the user can manipulate the priorities of therecord events. Alternatively, the priority of a particular event isaltered by having the user choose which program to record when aconflict occurs. For example, when a user decides to record a programand the priority manager determines that there is a conflict, whichindicates that a tuner will not be available for the entire duration ofthe program that is being scheduled to record, then the user ispresented with the option of recording the previously scheduled programor recording the current program.

If the user selects to record the previously scheduled program, then thecurrent program has the option of being recorded until the previouslyscheduled program begins. Also, the current program is given a lowerpriority in the priority manager than the conflicting record event. Ifthe user elects to record the current program, then the previouslyscheduled program is not recorded and the current program is given thehighest priority in the priority manager than the conflicting recordevent. Alternatively, the current program is given sufficient priorityto ensure that it is recorded ahead of the previously scheduledconflicting event. Often, the new event being scheduled is given apriority greater than the lowest priority event with which the eventbeing scheduled conflicts.

FIG. 3 identifies exemplary record events 222. A single record event 224occurs, for example, when a user identifies a program from the guidedata that is provided to the set top box and stored on the set top box.After the program is identified by the user, the user can choose torecord the event. The start time, end time, and other program attributesare typically determined from the guide data and the user is notrequired to provide this data to the set top box or the scheduler. Whena single record event 224 is finished recording, it is removed from therecord events 222.

A series record event 226 can also be identified from the guide data.The user typically identifies the program as a series and that the userdesires to record all programs of the series. For example, seriestelevision programs are typically shown on a weekly basis. Scheduling aseries record event 226 for a particular program causes the set top boxto record each episode of the selected program. The method by which theset top box identifies the program as a series is known in the art. Theseries record event 226 typically remains in the record events 222 evenafter a particular episode of a program finishes recording becausefuture episodes have not been recorded yet.

A single manual record event 228, on the other hand, typicallyidentifies a time block during which a particular channel is recorded bythe set top box. Certain attributes of the program being recorded, suchas those described herein, are not typically known. A repeated manualrecord event 230 is similar to a single manual record event 228, withthe difference that the repeated manual record event 230 occurs morethan once. For example, a user can create a single manual record event228 by causing the set top box to record a particular channel from 6:00p.m. to 8:00 p.m. on a particular Tuesday. The user can create arepeated manual record event 230 by causing the set top box to record aparticular channel from 6:00 p.m. to 8:00 p.m. on every Tuesday. Asingle manual record event 228 is removed from the record events 222after the recording terminates, while a repeated manual record event isnot necessarily removed from the record events 222.

FIG. 3 further illustrates other record events 232, which refers toother types of record events. One example of another record event is asmart record event. In a smart record event, the user indicates that heor she desires to record all programs that have a particular attributeor characteristic. The set top box or the scheduler is able to searchthe guide data for these attributes or characteristics. When a programis found that matches the attributes or characteristics, the program isscheduled as a record event by the scheduler in the priority manager.

For example, a user may desire to record all sporting events thatinclude a particular team. The scheduler can search the guide data tofind these events and schedule those that are found in the guide data.As new guide data is received by the set top box, the guide data issearched to determine if any future programs should be scheduled forrecording according to the smart record event.

Because this type of event is typically scheduled without input from theuser when it is scheduled, it is given a default priority in the recordevents of the priority manager. If there is a conflict, the conflict canbe brought to the attention of the user, for example, by displaying aconflict notice. If the conflict is not resolved, the events with higherpriority are given preference and are recorded before lower priorityevents are recorded.

FIG. 4 is a block diagram illustrating a priority manager. The prioritymanager 220 of FIG. 4 illustrates record events 222. The record events222 include all events that have been scheduled for recording in thisexample. As previously noted, other events may be managed and scheduledby the priority manager 220. This example includes event 402, 403 and404. The first event in the record events 222 is the event 402 and thelast event is the event 404. The order of the events in the recordevents 222 also illustrates the priority of the event. Thus, the event402, because it is the first listed event, has the highest priority. Theevent 404, because it is listed last, has the lowest priority of allevents in the record events 222. None of the events in the record events222 have the same priority.

FIG. 4 further illustrates how the priority manager may be used toprioritize scheduled events. When a user is scheduling a record event, aprogram 406 may be selected or identified from the guide data 405. Afterthe program is selected and if there is no conflict, the selectedprogram is scheduled as the lowest priority recording event in therecord events 222. The priority manger, however, can assign a priorityto any event including new events and the present invention is notlimited to assigning a lowest priority to newly scheduled record events.In some instances, the priority assigned to a particular event isreceived from the user. When a conflict is present, the new event may begiven the highest priority.

Alternatively, the user is able to give the newly scheduled event anassigned priority. The user has the option of inserting the newlyscheduled event at any point of the record events 220. In other words,the priority manager is typically displayed to the user and the user isable to view all of the scheduled events in the record events 222. Thenew event will be placed in the record events 222 by the prioritymanager 220 according to how the user resolves the conflict. If, forexample, the user decides to permit previously scheduled event to takepriority over the newly scheduled event, then the new event is placed atthe bottom of the record events 222 and has the lowest priority. In thismanner, a priority is assigned to each scheduled event managed by thepriority manager.

If the user decides to permit the new event to have priority over olderevents, the new event is inserted in the list of events one place higherthan the highest priority event that conflicts with the new event. Thus,if the new event conflicts with the event 403, then the new event wouldbe inserted above the event 403 and below the event 402. Alternatively,the new event can be inserted above the event 402 such that the newevent has the highest priority. The user can also manually insert theevent anywhere in the record events 222 of the priority manager 220.

In another example, the user may simply be informed that the event beingscheduled conflicts with an existing event. The user is then given theoption of either recording the existing event or of recording the newevent. If the user determines that he or she would rather record the newevent, then the new event is given a priority in the record events 222that is higher than the existing event or the new event is given thehighest priority. If the new event conflicts with multiple events, thenthe new event is given: a priority that is at least higher than thelowest priority event of the conflicting events, a priority that ishigher than the highest priority event of the conflicting events, or thehighest priority. If the user elects to record the previously scheduledevent, then the new event is still scheduled by the priority manager220, but it is given a lower priority than the conflicting events or thenew event is given the lowest priority. This enables the set top box torecord the event in the case where a higher priority event is deleted orrescheduled, for example.

The priority manager can have a default prioritization mechanism wherenew events are either assigned the highest priority or are assigned apriority that is higher than the highest priority event of conflictingevents. Conversely, when the new event is to be given a low priority,the priority manager can assign the lowest priority to the new event orcan assign a priority that is lower than the lowest priority of theconflicting events. In other words, various schemes can be used todetermine the priority of a new event. By giving the new event thehighest priority, the user is assured that this event will record. Bygiving the new event a priority that is higher than the lowest priorityof the conflicting events, it is possible that the event will not berecorded, especially if the number of conflicting events is greater thanthe number of tuners in the system. Thus, new events are preferablygiven the highest priority.

FIG. 4 also illustrates that the priority manager 220 is accessible frommultiple applications. As described above, the priority manager 220 isavailable from the scheduler 202 or when a user is scheduling an eventand resolving conflicts that arise with respect to the newly scheduledevent. The priority manager 220 is also accessible from the recordedprograms 408.

For example, a series record event is set to record a program on aweekly basis. One week, the recording does not occur. The user is ableto view a history log in the recorded programs 408 and discover thatother programs with higher priority were scheduled to record. As aresult, the series record event did not record. The user can access thepriority manager 220 and set the priority of the series record eventhigher.

If the user does not resolve a conflict when an event is scheduled, thenthe priority manager resolves conflicts between events in the eventlist. In one example, the programs are recorded according to theirpriority in the record events 222 of the priority manager 220. If theset top box has three tuners and four programs are scheduled toconcurrently record, then the program with the lowest priority will notbe recorded. As previously mentioned, the user can assign a new priorityto the unrecorded program, assuming that the program can be recorded inthe future. A single record event, for example, is deleted from therecord events 222 after it finishes recording or after its scheduledbroadcast time lapses.

When the user adjusts the priorities of recording events, the events areoften displayed to reflect their type. In other words, a user is able tovisually determine whether an event is a series record event, a manualrecord event, etc. This information can be used as needed by the user indetermining a priority for a particular event. Whenever there is achange in the priority of the events managed by the priority manager,the scheduler dynamically updates the event list of programs that are tobe recorded. The programs that will not be recorded can also bedisplayed to the user from various applications.

FIG. 5 illustrates an exemplary flow diagram for using a prioritymanager to record events. The priority manager uses user input toschedule an event (500). The event may be received, as previouslystated, from the guide data or any other source. The event may be arecord event or other type of event. While the priority manager isscheduling the event for the user, the scheduler (which may be a moduleof the priority manager in one embodiment) determines whether there is aconflict (501) with another event. If there is no conflict, the newevent is given a low priority (502) and the event is recorded asscheduled (507). Note that new event receives a low priority by default,but another priority may be assigned to the new event. The user and/orthe priority manager, for example, may assign the new event the highestpriority.

If a conflict exists between the new event and an existing event, thenthe user is given the opportunity to resolve the conflict (503). Thiscan occur generally by allowing the user to give the new event a higherpriority than older events (504). As previously described, the new eventis assigned or given a priority that is higher than the lowest priorityof the event that is in conflict with the new event. Alternatively, thenew event is assigned a priority that is lower than the existing events(505) that conflict with the new event. In one example, the new event isgiven the lowest priority. In both cases, the priority can be assignedor set by the user and the new event can be inserted at any point of therecord events in the record event list.

If the conflict is resolved (506), then the scheduled events arerecorded as scheduled (507). If the conflict is not resolved, then thepriority manager records or performs the events according to theirpriority in the event list of the priority manager (508). There are manysituations that may cause the conflict to not be resolved. For example,the event may be given lower priority than conflicting events. In thiscase, the event will only record when higher priority events aredeleted, rescheduled, etc. Alternatively, a conflict may not arise whenthe event is initially scheduled, but may arise later when the user isunable to resolve the conflict. A scheduled event may not end in atimely fashion and extend into another event, for example.

A conflict can also occur when the number of turners changes or when atuning resource is lost. For example, a tuner may stop working or may beremoved from the system in real-time. Alternatively, a record event withhigher priority may begin and take a tuner from a lower priority event.The lower priority event thus loses the tuner or the tuning resource.The priority manager can then determine which events to keep recordingor performing and which events are terminated based on the relativepriorities of the events in the priority manager. Other real-timeproblems may arise that result in a lost tuner(s) or in an eventconflict. In these and other situations, the events are recorded by thepriority manager according to their priority in the event list aspreviously described.

The present invention also addresses the issue of ensuring that there issufficient storage space to accommodate scheduled events. Often, it isnecessary to delete some of the recorded events or programs from thestorage of the recording device in these situations. A conflict can alsoarise when the recording device does not have sufficient storage spaceto accommodate future record events. For example, assume that arecording device is only able to store three (3) hours of video content.Further assume that there are four record events scheduled to record.The first three scheduled record events are recorded without difficulty.However, there is insufficient storage to successfully record the fourthrecord event.

This present invention addresses this issue by analyzing the recordedcontent and the guide data, which identifies future programs, such thatrecorded programs that are also broadcast in the future may be deletedand, at a later time, re-recorded. In this example, the first and thirdrecord events were one time events and will not be repeated in thefuture. A search of the guide data reveals that the second program willbe broadcast again in seven days. Thus, the second program is deletedfrom the storage to make room for the fourth program. The deletedprogram is then re-recorded when it is broadcast in the future. If nostorage space is available at that time, the above process may berepeated. If this process does not free storage space, then a defaultdelete process is invoked. In one example, the oldest recorded programis deleted to free storage for the new record event.

Thus, the system first determines that there is not sufficient storagespace to record a program. Next, it is necessary to estimate how muchstorage will be required for the program being recorded. This is done byexamining the guide data to determine the program duration, at whichpoint an estimation of the storage space can be made. The system thendetermines which programs or shows can be deleted. Each programtypically has a title and an identifier. The identifier is often uniqueand helps the system distinguish, for example, between episodes of atelevision series. Using this information from the shows that are storedon the recording device, the guide data is searched to determine whichof the recorded shows will be broadcast in the future.

After the system identifies which recorded programs will be broadcast inthe future, enough programs are deleted to free sufficient storage spaceto record the record event. An event is typically scheduled for thedeleted programs to ensure that they are re-recorded in the future. Ifinsufficient storage space exists at that time, the process is repeatedto ensure that all programs are successfully recorded on the recordingdevice. To prevent a program from being re-recorded repeatedly, theprogram may simply be deleted after it has been watched, after a certaintime period lapses, or after the same program has been recorded acertain number of times.

Another mechanism for freeing storage space is to use the prioritymanager. In this example, the priority manager can be used to prioritizerecorded programs for potential deletion. Thus, a recorded program withthe lowest priority will be deleted before a program of higher priority.When the events in the priority manager are recurring or series events,programs that were recorded because of a particular series event can bedeleted based on the priority of the series event in the prioritymanager. The order in which programs are deleted can vary. For example,all programs from the series event with the lowest priority may bedeleted before any programs from the next lowest series event aredeleted. Alternatively, the system may require that a program be deletedfrom each series event before a second program from a particular seriesevent is deleted. Other deletion schemes for deleting program based onthe priority manager are contemplated by the present invention.

The prioritization of recorded programs or shows for deletion can alsotake other factors into account. These factors or criteria include, butare not limited to, watched/unwatched, recording date, and the priority.Some recorded programs are protected, for example, by a “keep until”date function. Shows can be primarily prioritized for deletion based ontheir priority and secondarily prioritized on whether the program hasbeen watched or by the age of the recording based on the record date. Acombination of these factors can be implemented in a deletion scheme.

A program with a low priority will be deleted before a program with ahigh priority. For example, a program from a series event that has beenwatched may be deleted before a program from the same series event thathas not been watched. In another example, when two programs from thesame series event have both been watched by the user, the older programmay be deleted before the more recent program is deleted.

In another embodiment, a priority manager can be established forrecorded programs. In this instance, the priority manager will contain alist of recorded programs that are subject to deletion. Each program maybe associated with a date such as a keep until date. The user maydetermine or set the keep until date for each program in the prioritymanager for recorded programs. Some programs may have a keep until dateof “forever,” indicating that these shows are not to be deleted. Otherprograms may simply have dates. When storage space is required, the keepuntil dates can be examined and the program that will expire first ispre-aged and deleted. If more storage space is required, another programcan be aged and deleted in this manner. A user can use the prioritymanager for recorded shows to change these priorities as well. In otherwords, a priority manager for recorded programs determines whichprograms should be deleted according to their relative priorities justas a priority manager for record events determines which events arerecorded according to their relative priorities.

The present invention extends to both methods and systems for managingrecord events. The embodiments of the present invention may comprise aspecial purpose or general-purpose computer including various computerhardware, as discussed in greater detail below. The set top boxdiscussed herein in an example of a special purpose computer althoughthe set top box discussed herein may also be a general purpose computer.

Embodiments within the scope of the present invention also includecomputer-readable media for carrying or having computer-executableinstructions or data structures stored thereon. Such computer-readablemedia can be any available media that can be accessed by a generalpurpose or special purpose computer. By way of example, and notlimitation, such computer-readable media can comprise RAM, ROM, EEPROM,CD-ROM or other optical disk storage, magnetic disk storage or othermagnetic storage devices, or any other medium which can be used to carryor store desired program code means in the form of computer-executableinstructions or data structures and which can be accessed by a generalpurpose or special purpose computer. When information is transferred orprovided over a network or another communications connection (eitherhardwired, wireless, or a combination of hardwired or wireless) to acomputer, the computer properly views the connection as acomputer-readable medium. Thus, any such connection is properly termed acomputer-readable medium. Combinations of the above should also beincluded within the scope of computer-readable media.Computer-executable instructions comprise, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions.

FIG. 6 and the following discussion are intended to provide a brief,general description of a suitable computing environment in which theinvention may be implemented. Although not required, the invention willbe described in the general context of computer-executable instructions,such as program modules, being executed by computers in networkenvironments. Generally, program modules include routines, programs,objects, components, data structures, etc. that perform particular tasksor implement particular abstract data types. Computer-executableinstructions, associated data structures, and program modules representexamples of the program code means for executing steps of the methodsdisclosed herein. The particular sequence of such executableinstructions or associated data structures represents examples ofcorresponding acts for implementing the functions described in suchsteps.

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including personal computers, hand-held devices,multi-processor systems, microprocessor-based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, and thelike. The invention may also be practiced in distributed computingenvironments where tasks are performed by local and remote processingdevices that are linked (either by hardwired links, wireless links, orby a combination of hardwired or wireless links) through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

With reference to FIG. 6, an exemplary system for implementing theinvention includes a general purpose computing device in the form of aconventional computer 20, including a processing unit 21, a systemmemory 22, and a system bus 23 that couples various system componentsincluding the system memory 22 to the processing unit 21. The system bus23 may be any of several types of bus structures including a memory busor memory controller, a peripheral bus, and a local bus using any of avariety of bus architectures. The system memory includes read onlymemory (ROM) 24 and random access memory (RAM) 25. A basic input/outputsystem (BIOS) 26, containing the basic routines that help transferinformation between elements within the computer 20, such as duringstart-up, may be stored in ROM 24.

The computer 20 may also include a magnetic hard disk drive 27 forreading from and writing to a magnetic hard disk 39, a magnetic diskdrive 28 for reading from or writing to a removable magnetic disk 29,and an optical disk drive 30 for reading from or writing to removableoptical disk 31 such as a CD-ROM or other optical media. The magnetichard disk drive 27, magnetic disk drive 28, and optical disk drive 30are connected to the system bus 23 by a hard disk drive interface 32, amagnetic disk drive-interface 33, and an optical drive interface 34,respectively. The drives and their associated computer-readable mediaprovide nonvolatile storage of computer-executable instructions, datastructures, program modules and other data for the computer 20. Althoughthe exemplary environment described herein employs a magnetic hard disk39, a removable magnetic disk 29 and a removable optical disk 31, othertypes of computer readable media for storing data can be used, includingmagnetic cassettes, flash memory cards, digital versatile disks,Bernoulli cartridges, RAMs, ROMs, and the like.

Program code means comprising one or more program modules may be storedon the hard disk 39, magnetic disk 29, optical disk 31, ROM 24 or RAM25, including an operating system 35, one or more application programs36, other program modules 37, and program data 38. A user may entercommands and information into the computer 20 through keyboard 40,pointing device 42, or other input devices (not shown), such as amicrophone, joy stick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit21 through a serial port interface 46 coupled to system bus 23.Alternatively, the input devices may be connected by other interfaces,such as a parallel port, a game port or a universal serial bus (USB). Amonitor 47 or another display device is also connected to system bus 23via an interface, such as video adapter 48. In addition to the monitor,personal computers typically include other peripheral output devices(not shown), such as speakers and printers.

The computer 20 may operate in a networked environment using logicalconnections to one or more remote computers, such as remote computers 49a and 49 b. Remote computers 49 a and 49 b may each be another personalcomputer, a server, a router, a network PC, a peer device or othercommon network node, and typically include many or all of the elementsdescribed above relative to the computer 20, although only memorystorage devices 50 a and 50 b and their associated application programs36 a and 36 b have been illustrated in FIG. 6. The logical connectionsdepicted in FIG. 6 include a local area network (LAN) 51 and a wide areanetwork (WAN) 52 that are presented here by way of example and notlimitation. Such networking environments are commonplace in office-wideor enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 20 is connectedto the local network 51 through a network interface or adapter 53. Whenused in a WAN networking environment, the computer 20 may include amodem 54, a wireless link, or other means for establishingcommunications over the wide area network 52, such as the Internet. Themodem 54, which may be internal or external, is connected to the systembus 23 via the serial port interface 46. In a networked environment,program modules depicted relative to the computer 20, or portionsthereof, may be stored in the remote memory storage device. It will beappreciated that the network connections shown are exemplary and othermeans of establishing communications over wide area network 52 may beused.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

1. In a system that includes tuner resources, wherein tuner resourcesare required to perform record events in the system and wherein one ormore record events are scheduled to record by using the tuner resources,a method for managing the record events such that the events arerecorded according to their priority at least when a tuning resource isunavailable, the method comprising: maintaining a record event list witha priority manager, wherein the record event list includes one or morerecord events that have different priorities; scheduling a new event,wherein scheduling the new event creates a conflict when a tuningresource is unavailable, the conflict being created with at least oneother event that is already included in the record event list; assigninga priority to the new event; determining the record events to recordwhen a tuning resource is unavailable, based on priorities of the recordevents in the record event list; and performing the record events in therecord event list that have the highest priority.
 2. A method as definedin claim 1, wherein determining the record events to record comprisesdetermining that at least one tuning resource has become unavailableduring a record event and wherein performing the record event comprisescontinuing recording of record events based on priorities of the recordevents in the record event list.
 3. A method as defined in claim 1,wherein assigning a priority to the new event comprises assigning thenew event a higher priority than at least one conflicting event in therecord event list.
 4. A method as defined in claim 1, wherein assigninga priority to the new event comprises assigning the new event a lowerpriority than at least one conflicting event in the record event list.5. A method as defined in claim 1, further comprising recording eventswith the highest priorities even when a conflict with another event isunresolved, wherein the conflicting events that have the lowest priorityare not recorded.
 6. A method as defined in claim 1, further comprisingassigning a default priority to the new event when the new event doesnot conflict with an event that is already scheduled.
 7. A method asdefined in claim 1, wherein determining the record events to record whena tuning resource is unavailable further comprises: determining thatthere is insufficient storage to perform the record events in the recordevent list; and deleting at least one program from the storage such thatthere is sufficient storage to perform a pending event in the recordevent list.
 8. A method as defined in claim 7, wherein deleting at leastone program from the storage such that there is sufficient storage toperform a pending event in the record event list further comprises:identifying each program stored in the storage; searching guide data todetermine a program stored in the storage that is broadcast in thefuture; deleting only programs scheduled for broadcast in the future;and re-recording each deleted program at a later time.
 9. A method asdefined in claim 7, wherein deleting at least one program from thestorage such that there is sufficient storage to perform the events inthe record event list further comprises at least one of: using thepriority manager to identify programs for deletion based on a priorityof the recorded programs; and using criteria to determine which programsare deleted, wherein the criteria includes each of whether a recordedprogram is watched or unwatched, when a program was recorded, and apriority of the recorded program.
 10. A method as defined in claim 7,wherein deleting at least one program from the storage such that thereis sufficient storage to perform a pending event in the record eventlist further comprises deleting at least one program using a prioritymanager for recorded programs, wherein the priority manager for recordedshows prioritizes the recorded programs such that recorded programs withthe lowest priority are deleted in order to perform the events in therecord list.
 11. In a system that records video streams received from asource, a method for prioritizing record events to determine which videostreams are recorded when a tuning resource of the system is unavailablesuch that the system does not have sufficient tuning resources to recordall of the record events, the method comprising: scheduling one or morerecord events in an event list, wherein each of the record events in theevent list has an associated priority; establishing a priority for newrecord events in the event list, the priority for each new record eventbeing established by a a priority manager; determining whethersufficient tuning resources are available to record each of the recordevents in the event list; when one or more tuning resources areunavailable, such that more record events are currently scheduled thanthere are available tuning resources, determining which record events torecord when a tuning resource is unavailable based on priorities of therecord events in the event list, and thereby recording the record eventsin the event list that have the highest priority.
 12. A method asdefined in claim 11, wherein scheduling one or more record events in anevent list further comprises: scheduling a single record event;scheduling a series record event; scheduling a single manual recordevent; scheduling a repeated manual record event; and scheduling a smartrecord event.
 13. A method as defined in claim 11, wherein establishinga priority for new record events in the event list further comprises oneof: for a new event, assigning the new event a priority that is higherthan the lowest priority of those record events in the event list thatconflict with the new event; or for the new event, assigning the newevent a priority that is lower than those record events in the eventlist that conflict with the new event.
 14. A method as defined in claim11, wherein establishing a priority for new record events in the eventlist further comprises receiving an assignment of priority for at leastone of the events in the event list from a user.
 15. A method as definedin claim I 1, further comprising altering the priorities of the recordevents in the event list from another application.
 16. A method asdefined in claim 11, wherein determining which record events to recordwhen a tuning resource is unavailable comprises determining which recordevents to keep recording when a tuning resource becomes unavailableduring recording of a record event in the event list, whereinunavailability of the tuning resource creates a conflict between recordevents.
 17. A computer-program product for use in a system that includestuner resources, wherein tuner resources are required to perform recordevents in the system and wherein one or more record events are scheduledto record, the computer program product storing computer-executableinstructions for managing the record events when one or more tuningresources are unavailable and such that the events are recordedaccording to their priority, the computer-executable instructions, whenexecuted, causing the system to: maintain a record event list with apriority manager, wherein the record event list includes one or morerecord events that have different priorities; schedule a new event basedon user input, wherein scheduling the new event creates a conflict whena tuning resource is unavailable, the conflict being created with atleast one other event that is already included in the record event list;assign a priority to the new event; determine the record events torecord when a tuning resource is unavailable, based on priorities of therecord events in the record event list; and perform the record events inthe record event list that have the highest priority.
 18. Acomputer-program product as defined in claim 17, wherein the computerprogram product is a set-top box.
 19. A computer-program product asdefined in claim 17, wherein the priority assigned to the new event isreceived from the user.
 20. A computer-program product as defined inclaim 17, wherein the computer-executable instructions, when executed,further cause the system to record events with the highest prioritieseven when a conflict with another event is unresolved or a tuningresource is unavailable, wherein conflicting events that have the lowestpriority are not recorded.